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ABSTHACT 


Due  to  the  speed  and  complexity  of  communication  networks  being  designed  today,  it 
is  imperative  to  ensure  that  they  operate  correctly.  Todays  fiber  optic  networks,  which  can 
transmit  billions  of  bits  per  second  over  thousands  of  miles,  are  heavily  dependent  on 
sophisticated  software  and  protocols  which  are  becoming  increasingly  difficult  to  test. 
Conformance  testing  is  a  method  that  is  used  for  this  purpose;  to  test  the  design  of  a 
protocol  against  an  Implementation  of  the  design.  This  thesis  provides  some  insight  into  the 
conformance  testing  problem  by  first  providing  background  on  some  current  protocol  test 
methods,  and  then  focusing  on  a  newer  method,  which  is  based  on  a  formal  protocol 
specification.  A  proof  is  given  that  demonstrates  the  method’s  error  detection  capabilities 
Two  well  known  local  area  network  protocols.  Token  Bus  and  Fiber  Distributed  Data 
Interface  (FDDI),  are  used  as  examples  to  illustrate  how  the  test  method  is  applied  to  a 
specification. 
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1.  INTRODUCTION 


A.  BACKGROUND 

Protocols,  in  the  simplest  sense,  are  rules  and  procedures  that  control  the  flow  of 
infonnation.  For  centuries,  long  before  any  device  that  even  resembles  a  modem  day 
computer  was  ever  conceived,  mankind  has  struggled  with  designing  precise  and  efficient 
communication  protocols.  In  the  2nd  century  B.C..  when  communication  protocols 
consisted  of  fire  signals,  it  was  observed  by  the  Greek  historian  Polybius  that  “  ..it  is  chiefly 
unexpected  occurrences  which  require  instant  consideration  and  help."  Essentially,  he 
noted  that  it  was  impossible  to  have  a  preconceived  code  using  fire  signals  that  could 
communicate  these  unexpected  occurrences  [HOLT91].  In  modem  day  communication 
protocols,  it  is  still  the  unexpected  sequence  of  events  that  often  leads  to  protocol  failures, 
and  the  most  difficult  problem  in  protocol  design  is  precisely  that  --  to  expect  the 
unexpected. 

The  first  electronic  communication  protocols  based  on  the  use  of  the  telegraph  also 
encountered  the  problems  associated  with  conununicating  unexpected  events.  However, 
there  was  almost  always  a  human  operator  involved  who  could  be  relied  upon  to  handle 
these  problems.  In  current  communication  systems,  when  machines  and  processes  rather 
than  human  operators  are  used,  the  same  problems  exist  but  now  the  errors  can  happen 
faster  and  human  intervention  cannot  be  counted  on  to  recover  from  unexpected 
occurrences.  The  protocol  design  problem  is  now  to  determine  the  responsibilities  of  these 
processes  and  to  estsd^lish  procedures  so  that  these  responsibilities  can  be  negotiated.  In 
other  words,  there  should  be  rules  that  govern  the  exchange  of  information,  but  there  should 
also  be  an  agreement  between  the  communicating  parties  about  the  rules. 

Designers  of  early  networks  such  as  the  ARPAnet  learned  that  ambiguous  rules  can 
trigger  unlikely  sequences  of  events  which  will  ruin  even  the  best  design.  Entire  networks. 


with  thousands  of  attached  computers  can  be  rendered  completely  useless  by  a  faulty 
protocol.  Advances  in  network  and  teleconunuiiication  technology  have  resulted  in 
increasingly  complex  communication  protocols.  Though  electronic  ctimmunication 
protocols  have  been  around  for  many  years,  it  is  only  recently  that  their  complexity  has 
begun  to  dramatically  increase.  Networks  capable  of  transmitting  billions  of  bits  per  second 
over  thousands  of  miles  are  now  in  use.  Consequently,  the  protocols  being  developed  today 
are  larger  and  more  sophisticated  than  ever  before.  They  try  to  offer  more  functionality  and 
reliability,  but  as  a  result  they  have  increased  in  size  and  in  complexity  Tliis  is  due  to  a 
number  of  factors,  most  notably  the  increased  speed  and  capacity  of  current  networks,  hut 
also  the  desire  to  make  the  most  efficient  use  of  available  resources. 

Because  of  society's  critical  dependence  on  communication  networks  and  protocols, 
it  is  imperative  to  adequately  test  them  to  ensure  they  perform  as  intended.  This  is  the  goal 
of  conformance  testing. 

B.  OBJECTIVES 

In  this  thesis,  a  conformance  test  method  based  upon  a  formal  specification  of  a 
protocol  will  be  investigated.  This  will  include  a  review  of  some  recent  confonnance  test 
procedures,  along  with  a  discussion  of  the  potential  shortcomings  which  make  them  less 
than  ideal  for  testing  real-world  protocol  implementations.  The  conformance  test  method 
presented  here  is  an  improvement  based  upon  earlier  work  [LUND90(b)]. 

The  major  contributions  of  this  thesis  are: 

•  an  improved  conformance  test  method 

•  a  proof  that  demonstrates  the  method’s  error  detection  capabilities 

•  applications  of  the  test  method  using  real  world  protocols  such  as  IEEE 
802.4  (Token  Bus)  and  ANSI  X3T9  5  (FDDI) 

Techniques  for  designing  a  protocol  to  allow  for  greater  testability  will  also  be  di.scu.ssed. 
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C.  SCOPE 


Specifically,  the  goal  of  conformance  testing  of  conununication  protocols  is  used  to 
verify  that  the  behavior  of  a  protocol  implementation  is  consistent  with  its  specification. 
Since  much  effort  is  put  into  formally  specifying  and  verifying  protocols,  it  is  at  least 
equally  important  to  test  a  given  implementation  for  functional  correctness  If  a  fonnal 
specification  of  a  protocol  contains  an  error,  a  correct  implementation  of  that  specification 
should  pass  a  conformance  test  only  if  it  contains  the  same  error.  In  other  words,  a 
confonnance  test  should  fail  when  the  implementation  and  specification  differ.  Tlie  test  is 
developed  from  a  protocol's  fonnal  specification  and  is  applied  to  an  implementation  of  the 
protocol,  preferably  in  a  systematic  manner.  This  situation  is  shown  in  Figure  I . 


Formal 

Protocol 

Specification 

Tester 

input.';  ^ 

Protocol 

^  cutouts 

Implementation 

Figure  1  :  Conceptual  View  of  Conformance  Testing 


For  all  practical  purposes  we  assume  that  the  protocol  unplementation  is  essentially 
unknown.  In  other  words  it  is  simply  a  “black  box,”  meaning  that  the  test  designer  knows 
nothing  about  its  internal  workings.  Tlie  only  t)rpc  of  experiment  we  can  do  with  the 
implementation  is  to  provide  it  with  sequences  of  inputs  and  observe  the  resulting  outputs. 
This  black  box,  commonly  referred  to  as  an  implementation  under  test  (lUT)  in  the 
literature,  passes  the  confonnance  test  only  if  all  observed  outputs  match  those  prescribed 
by  the  formal  specification  [HOLT911.  It  is  difficult  to  test  a  protocol  implementation  in 
isolation  because  many  protocol  suites  are  composed  of  a  number  of  independent  layers. 
Since  the  layers  are  independent,  and  can  be  part  of  a  number  of  different  protocol  suites, 
they  should  be  tested  as  independent  entities.  Figure  2  shows  the  relationships  of  these 
entities. 


N  +  1 


Figure  2  :  Testing  an  Independent  Layer 


In  Figtue  2,  protocol  layer  N  is  the  actual  implementation  under  test.  Since,  in  the 
normal  operation  of  this  protocol,  layer  N  must  interface  with  upper  and  lower  layer 
protocols,  it  needs  to  be  tested  in  that  context.  The  arrows  between  the  protocol  layers 
indicate  the  flow  of  data  that  occurs  in  the  actual  implementation. 

D.  ORGANIZATION 

This  thesis  contains  six  chapters.  Chapter  11  discusses  some  issues  uilierent  in 
conformance  testing,  and  provides  four  example  test  methods  currently  in  use  A  brief 
definition  of  the  systems  of  communicating  machines  protocol  model  is  also  given.  In 
Chapter  HI,  the  test  method  is  presented  in  detail.  Chapter  IV  is  concerned  with  the 
generation  of  test  sequences  for  two,  well  known  local  area  network  protocols;  Token  Bus 
and  FDDI.  This  ch^ter  also  includes  a  discussion  of  the  fault  coverage  provided  by  the  test 
sequences  as  well  as  suggestions  for  improving  the  testability  of  the  protocol  specification. 
A  proof  of  the  fault  coverage  provided  by  this  test  method  is  given  in  Chapter  V  This  thesis 
is  concluded  with  Chapter  V!  with  discussions  on  the  contributions  of  this  research  and 
ideas  for  further  research  in  conformance  testing. 
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n.  CONFORMANCE  TESTING 


A.  FUNCTIONAL  TESTING 

In  order  to  understand  how  connnunication  protocols  can  be  tested,  it  is  necessary  to 
understand  why  testing  is  an  important  issue.  In  large,  complex  communication  networks, 
administrators  need  a  way  to  verify  that  a  certain  piece  of  equipment  eonfonns  to  a 
prescribed  standard,  In  an  environment  where  thousands  of  phone  calls  or  gigabits  of  data 
are  being  switched  each  second,  it  is  not  acceptable  to  test  equipment  by  plugging  it  into 
the  network.  Ideally,  we  would  like  to  verify  conformance  to  the  standard  without 
necessarily  having  access  to  the  often  proprietary,  internal  details  of  the  equipment. 

According  to  [HOLT9I].  there  are  two  basic  goals  of  functional  testing; 

•  To  establish  that  a  given  implementation  realizes  all  functions  of  the  original 
specification,  over  the  full  range  of  parameter  values. 

•  To  establish  that  a  given  implementation  can  properly  reject  erroneous  inputs 
in  a  way  that  is  consistent  with  the  original  specification. 

The  trade-offs  encountered  in  these  tests  are  mainly  between  complexity  and 
standardization.  It  is  extremely  unlikely  that  a  test  method  could  be  devised  that  could  test 
all  possible  behaviors  of  an  unknown  implementation  by  simply  probing  it  and  observing 
its  responses.  In  the  conformance  testing  of  protocols,  only  the  presence  of  desirable 
behavior  can  be  tested.  We  cannot  test  for  the  presence  of  undesirable  behavior  because 
there  is  always  the  possibility  that  some  untested  sequence  of  inputs  will  reveal  a  flaw  in 
the  implementation. 

B.  SPECBFICATION  CONFORMANCE 

The  process  of  conformance  testing  is  based  on  the  generation  of  test  sequences.  These 
test  sequences  attempt  to  exercise  all  parts  of  the  protocol  machine  as  they  are  defined  in 
the  specification.  In  the  literature,  the  actual  machine  being  tested  is  referred  to  as  the 


Implementation  Under  Test  (ItHT).  Some  recent  tonfomiance  testing  procedures  involve 
the  use  of  incompletely  specified  finite  state  machines  with  input/output  labels  on  the 
transitions.  The  usual  approach  here  is  to  represent  the  control  portion  of  a  protocol  as  a 
finite  state  machine  (FSM)  and  generate  a  test  sequence  in  the  fonn  of  an  input/output 
sequence  such  that,  if  the  ILT  confonns  to  the  specification,  the  application  of  the  above 
input  sequence  will  generate  the  corresponding  output  sequence  as  specified  in  the  test 
sequence.  Since  many  protocols  are  not  specified  in  the  manner  described  above  (l  e  as 
FSMs),  an  approach  such  as  this  may  compticate  the  task  of  the  test  designer. 

The  common  procedure  followed  by  many  current  test  methods  is  to  test  each  edge  of 
the  FSM  individually,  then  combine  the  edge  sequences  together  to  for.n  a  test  se(|uence 
Before  discussing  some  specific  test  methods  however,  it  is  necessary  to  state  some 
simplifying  assumptions.  First,  we  assume  that  the  reference  specification  being  modelled 
is  a  deterministic  FSM  with  a  known  number  of  states.  Second,  the  output  sequence  emitted 
by  the  machine  occurs  within  a  known,  finite  amount  of  time  after  the  input  sequence 
Finally,  every  state  in  the  FSM  is  reachable  from  every  other  state  via  one  or  more  state 
transitions.  For  the  purposes  of  this  discussion,  a  stare  of  an  FSM  (or  stop-state  as  it  is 
sometimes  called)  is  defined  as  a  stable  condition  in  which  the  machine  is  awaiting  an  input 
sequence.  A  transition  is  defined  as  the  consumption  of  an  input  signal,  the  possible 
emission  of  an  output  signal,  and  the  possible  move  to  a  new  state 

C.  CURRENT  TEST  METHODS 

The  FSMs  used  to  model  a  protocol  specification  are  commonly  represented  by 
directed  graphs.  In  a  given  graph,  an  edge  (v.h  )  with  a  label  a/b  means  that  if  the  machine 
is  currently  in  state  v,  then  it  will  change  to  state  w'  and  output  the  symbol  h  if  and  only  if 
the  current  input  symbol  is  a.  Many  recent  test  methods  employ  his  notation  Another 
similarity  between  a  number  of  methods  is  the  use  of  Unique  Inpur/Output  sequences  ( UIO 
sequences).  UIO  sequences  are  used  within  the  test  sequence  to  enhance  the  correctness  of 
the  test.  For  a  given  state  within  an  FSM,  a  UIO  sequence  can  be  defined  as  a  sequence  of 
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input/output  pairs  which  can  only  be  observed  when  that  input  sequence  is  applied  to  that 
state.  The  purpose  of  such  a  sequence  is  to  ensuie  the  patli  by  which  a  gnen  state  was 
reached.  Figure  3  shows  how  the  notation  is  u.sed  to  label  the  transitions  in  an  actual  IIT 
This  example  was  taken  from  [YANGVOj  and  is  used  because  it  facilitates  comparisons 
between  the  different  methods. 

All  of  the  states  in  the  lUT  in  Figure  3  have  one  or  more  UIO  sequences  For  exatnple. 
the  sequence  alx  hix  is  u  UIO  sequence  for  state  i  because  from  no  other  state  can  we  input 
a  b  and  have  the  machine  output  x  .v.  Similarly,  a  possible  LTO  sequence  for  state  is  (  - 
because  from  no  other  state  can  we  input  c  and  have  the  machine  output  z.  Hie  complete 
list  of  UIO  sequences  for  this  implementation  is  given  in  Table  1.  UIO  sequences  are 
important  because  of  their  uniqueness.  That  is,  they  can  be  used  to  verify  their 
corresponding  state. 
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TABLE  1:  UlO  SEQUENCE  FOR  FIGURE  3 


State 

UIO  sequence 

Tail  state 

1 

b/x  a/x 

5 

1 

a/x  b/x 

2 

1 

a/x  c/y 

4 

1 

a/x  a/x 

1 

1 

b/x  b/y 

3 

1 

c/y  a/x 

5 

1 

c/y  b/x 

3 

2 

b/y 

3 

3 

b/x  c/z 

1 

3 

b/x  a/x 

4 

3 

c/y  a/z 

4 

3 

c/y  c/z 

5 

4 

b/x  c/y 

5 

4 

b/x  b/x 

5 

5 

c/z 

1 

5 

a/z 

4 

As  was  mentioned  in  Chapter  I,  the  tester  cannot  view  the  internal  structure  of  the 
implementation.  The  only  knowledge  the  tester  has  about  the  lUT  are  the  outputs  it  emits 
in  response  to  the  inputs  supplied.  For  this  reason.  UIO  sequences  are  very  important.  They 
allows  us  to  determine  the  state  of  the  machine  before  we  supplied  the  input  sequence.  Tlie 
column  labelled  "Tail  State”  in  Table  1  is  simply  the  state  the  machine  should  be  in  after 
we  supplied  the  input  sequence.  Detennining  the  UIO  sequences  for  each  state  is  an 
important  first  step  for  many  test  procedures.  TTie  remainder  of  this  chapter  describes  some 
recent  protocol  test  procedures. 
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1.  U-Method 


TTie  U-method  (SABN851  was  one  of  the  first  methods  used  in  protocol  testing 
Essentially,  it  consists  of  3  parts; 

(1)  the  RESET  transition  plus  the  sequence  from  the  initial  machine  state  to  the 
starting  state  of  the  edge  being  tested.  (The  purpose  of  the  RESET  transition  is  to  "reset" 
the  machine  into  its  initial  state,  state  1  for  this  machine. ) 

(2)  the  label  on  the  edge  or  transition  being  tested. 

(3)  the  shortest  UIO  sequence  for  the  ending  state  (tail  state)  of  this  edge. 

The  complete  test  sequence  using  the  U-Method  is  given  in  Table  2.  A  complete  test 
sequence,  or  test  suite,  consists  of  the  concatenation  of  the  first,  second  and  third  parts  of 
every  test.  The  reader  may  verify  that  there  arc  77  steps  in  the  entire  test  sequence. 


TABLE  2:  TEST  SEQUENCE  FOR  FIGURE  3  BY  THE  U-METHOD 


Edge 

Index 

Edge 

Tested 

Label 

Tested 

Parti 

Part  2 

— 

Part  3 

el 

l-»l 

RESET 

RESET 

RESET 

hi  x  iiix 

e2 

l-)l 

a/.\ 

RESET 

a/.x 

hi  x  0!  X 

e3 

l->2 

h/x 

RESET 

N\ 

hiv 

e4 

l-»4 

dy 

RESET 

tvv 

Iti.x  c/v 

e5 

2->l 

RESET 

RESET  bl.x 

RESET 

h/x  a/  x 

e6 

2->3 

bly 

RESET  bl.x 

b/y 

b/x  c/r 

el 

2->5 

atx 

RESET  b/x 

a/x 

dz 

e8 

RESET 

RESET  dy  b/x 

RESET 

b/x  a/x 

e9 

3^5 

b/x 

RESET  dy  b/x 

b/x 

mm 

elO 

3-45 

.  . 

dy 

RESET  dv  b/x 

dy 

(d  z 

ell 

4-41 

RESET 

RESET  dy 

RESET 

t}/\  ai  r 

el2 

4-43 

hi.x 

RESET  dy 

h/x 

hi  r  11  z 

el3 

4-45 

al.x 

RESET  c/v 

('  z 

el4 

5-41 

RESET 

RESETdya/x 

RESET 

hi  \  <11 X 

Edge 

Index 

Edge 

Tested 

Label 

Tested 

_ 

Part  1 

Part  2 

Part  3 

eI5 

5^1 

1 1 

RESET  IV  <j/.v 

r 

hi  \  ill  < 

el6 

5-^4 

RESET  t  IV  <j/r 

hii  1  ‘v 

The  U-Method  does  not  specify  a  panicular  order  in  which  to  test  the  edges;  it  is 
up  to  the  tester  to  ensure  that  all  transitions  are  exercised  This  example  begins  in  the  initial 
machine  state  (stare  I),  and  attempts  to  test  the  RESET  transit'on  from  stare  I  to  state  I . 
The  first  part  of  this  test  is  the  sequence  from  initial  state  to  the  starting  state  of  the  edge, 
in  this  case  since  we  want  to  test  a  transitions  emanating  from  the  initial  state,  only  the 
RESET  transition  needs  to  be  executed.  The  second  part  of  this  test  is  the  actual  label  on  the 
transition,  and  the  third  part  is  the  UIO  sequence  for  the  state  in  which  this  test  ends  (state 
1  in  this  example).  The  second  test  in  the  sequence  is  the  a/x  transition  from  state  I  to  state 
/.  The  first,  second,  and  third  parts  are  RESET,  aix,  and  blx  a/x,  respectively.  Note  that,  if 
a  state  has  more  than  one  UIO  sequence,  we  simply  choose  one  of  the  shortest,  and  use  it 
throughout  the  entire  test  whenever  the  edge  being  tested  ends  in  that  state. 

2.  RCP-Me(hod 

The  RCP-method  [AH088]  is  sinular  to  the  U-Method  in  that  it  uses  the  test 
sequence  generated  by  the  U-Method  as  a  starting  point.  It  essentially  concatenates  the 
second  and  third  parts  of  the  U-method  to  form  what  is  sometimes  called  a  compound  edge. 
A  graph  consisting  of  the  compound  edges  is  then  constructed,  and  the  Rural  Chinese 
Postman  algorithm  is  used  to  find  the  shortest  path  in  the  graph  which  traverses  each  edge 
at  least  once.  Since  this  method  eliminates  the  process  of  visiting  the  initial  state  after  each 
edge  sequence,  (part  1  of  the  U-method)  it  results  in  significantly  shorter  test  sequences. 
The  test  sequence  for  our  example  machine  by  the  RCP-Method  is  given  in  Table  3 
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TABLE  3:  TEST  SEQUENCE  FOR  FIGURE  3  BY  THE  RCP-METHOD 


mm 

Edge 

Label 

UIO 

Connection 

End 

Tested 

Tested 

Sequence 

Path 

State 

N/A 

N/A 

RESET 

- 

■ 

i 

1 

1^2 

h/x 

biv 

- 

3 

3 

3-H.5 

UDI 

f  z 

- 

1 

1 

l-4l 

tJ/A 

hi.x  ui.x 

3 

3 

a/z 

bi.x  (./v 

- 

3 

5 

5^1 

or 

bi.x  ii/  x 

- 

3 

5 

5-^1 

RESET 

hi  t  ai\ 

a^z 

4 

4 

4-^3 

i7Jx 

I'tZ 

- 

1 

1 

I ->4 

dy 

bl\  dy 

alz  bi.x 

3 

3 

3-»5 

bix 

d: 

bi.x 

2 

2-^3 

bly 

bi.x  dz 

b>.x 

1 

2 

2-45 

at.x 

dz 

bi.x 

2 

2->l 

RESET 

bi.x  a/.x 

alz  bi.x 

3 

3 

3^1 

RESET 

bi.x  at.x 

OiZ 

4 

4 

4-43 

bis 

bi.x  dz 

■ 

1 

1 

l-4l 

RESET 

bi.x  al.x 

alz 

4 

4 

4-41 

RESET 

bi.x  al.x 

dz 

1 

The  test  sequence  in  Tabie  3  is  constructed  from  the  graph  that  is  generated  from 
the  RCP  tour  of  Figure  3.  (See  detail  in  (AH088]).  The  compound  edge  is  formed  by  the 
concatenation  of  the  “Label  Tested”  and  “UIO  Sequence”  columns.  Since  it  is  not 
necessary  to  visit  the  initial  machine  state  after  the  test  of  each  edge,  this  method  simply 
selects  one  of  the  outgoing  edges  from  the  ending  state  of  the  previous  test  for  the  next  test. 
For  example,  we  start  the  test  with  the  machine  in  an  unknown  state,  so  the  RESET 
transition  is  necessary  to  bring  the  machine  to  its  initial  state  {state  I ).  The  hix  transition 
emanating  from  state  1  is  then  tested  and  its  UIO  sequence.  bly\  executed,  putting  the 
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machine  in  stare  3.  From  state  3,  the  r/v  transition  is  tested  and  its  nO  sequence  executed, 
putting  the  machine  in  state  I.  The  test  sequence  continues  in  such  a  manner  until  it  arrives 
at  a  state  that  has  no  untested  outgoing  transitions.  At  this  point  it  is  necessar>'  to  execute  a 
"connection  path"  transition,  which  takes  the  machine  to  a  state  which  has  at  least  one 
untested  transition.  From  here,  the  test  proceeds  as  before.  The  reader  may  verify  that  there 
are  55  steps  in  the  complete  test  sequence,  with  the  reduction  being  achieved  by  eliminating 
from  the  test  sequence,  the  path  from  the  initial  state  to  the  edge  being  tested 

3.  MUlO-Method 

In  [SHEN89]  it  was  shown  that  even  shorter  test  sequences  can  be  obtained,  with 
the  RCP-method  if  multiple  LTO  <MU10)  sequences  from  each  state  are  used.  The  idea 
behind  multiple  UlO  sequences  is  to  reduce  the  repetition  that  results  from  having  to  follow 
the  same  UIO  sequence  every  time  an  edge  sequence  reaches  a  given  state.  The  number  of 
times  the  UIO  sequence  for  a  given  state  will  be  repeated  is  greater  than  or  equal  to  the 
indegree  of  that  state.  By  allowing  the  use  of  different  shortest  UIO  sequences,  there  is  an 
increased  possibility  that  we  can  find  a  UIO  sequence  that  will  end  at  a  state  with  an 
untested  outgoing  transition;  this  effectively  reduces  the  number  of  connection  paths 
necessary  and,  hence,  reduces  the  length  of  the  sequence.  The  te.st  sequence  for  Figure  y  by 
the  MUIO-method  is  shown  in  Table  4. 


TABLE  4:  TEST  SEQUENCE  FOR  FIGURE  3  BY  THE  MUIO-METHOD 


Start 

Edge 

Label 

UIO 

End 

State 

Tested 

Tested 

Sequence 

State 

N/A 

N/A 

RESET 

- 

1 

1 

l-4l 

a/x 

a/x  b/x 

2 

2 

2-»l 

RESET 

a/x  b/x 

-> 

2 

2-»3 

b/y 

b/x  c/z 

1 

1 

I-*2 

b/x 

b/y 

3 

3 

3-»l 

RESET 

c/y  b/Sx 

3 

12 


Start 

Edge 

Label 

UIO 

End 

State 

Tested 

Tested 

Sequence 

State 

3 

mggi 

b/n 

c/z 

1 

1 

i~*i 

RESET 

c/y  b/x 

3 

3 

3~^5 

c/y 

c/z 

1 

1 

t— >4 

c/y 

b/x  c/y 

3 

5 

5-^4 

a/z 

b/.T  c/y 

s 

5 

5-»t 

RESET 

c/y  a/.x 

5 

5 

5->l 

dz 

a/x  c/y 

4 

4 

4-^1 

RESET 

a/x  b/x 

2 

2 

2-^5 

a/.i 

a/z 

4 

4 

4->3 

b/x 

b/x  .t/z 

im 

4 

■B 

a/.T 

c/z 

1 

The  test  sequence  presented  in  Table  4  consists  of  44  steps,  less  than  both  the  U- 
Method  and  RCP-Method.  It  is  1 1  steps  shorter  than  the  RCP-Method,  because  it  eliminates 
the  1 1  connection  path  transitions  associated  with  the  RCP-Method.  The  procedure  for 
generating  this  sequence  is  quite  complicated  and  is  not  discussed  here.  Interested  readers 
way  consult  (SHEN89]. 

4.  MUIO*Method  with  Overlapping 

In  1TANG90]  it  was  shown  that  multiple  UIO  sequences  can  be  combined  with 
overlapping  to  further  condense  the  test  sequence.  Overlapping  takes  advantage  of  the  case 
where  some  ending  portion  of  an  edge  sequence  is  identical  to  the  beginning  portion  of 
another  edge  sequence.  Since  the  length  of  the  test  sequence  is  now  dependent  upon  the 
length  of  the  compound  edges,  one  possible  way  to  reduce  the  length  is  to  combuie  the 
compound  edge  of  one  test  with  the  next  edge  to  be  tested.  Thus,  when  possible,  tlie.se  two 
edge  sequences  are  combined  to  form  one  edge  sequence  which  can  be  used  to  test  both 
edges.  By  using  several  shortest  UIO  sequences,  there  is  a  good  chance  that  an  "untested" 
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LflO  sequence  can  be  used  to  verify  that  state.  A  shorter  test  sequence  can  now  be  obtained 
because  the  untested  UIO  sequence  is  both  verifying  the  previous  state,  and  bcgiiuiutg  the 
test  of  a  different  transition  emanating  from  that  state.  Essentially,  a  different  incoming 
edge  of  a  state  is  concatenated  with  a  different  shortest  UIO  sequence  which  completes  the 
second  half  of  the  current  compound  edge  and  begins  the  first  half  of  a  new  compound 
edge. 

For  example,  the  compound  edge  for  the  edge  4->5  labeled  al\  in  Figure  ^  is  a  x 
dz,  and  the  compound  edge  for  the  edge  5-»l  labeled  dz  is  dz  aix  d\.  With  overlapping, 
the  two  compound  edges  can  be  combined  into  the  single  sequence  aix  ciz  a/x  tv  v  which 
can  be  used  to  test  both  edges.  The  procedure  given  in  fYANG90]  shows  how  to  combine 
the  maximum  number  of  compound  edges  using  multiple  UTO  sequences  and  overlapping. 
When  a  sequence  is  derived  that  contains  the  maximum  number  of  compound  edges,  that 
sequence  is  often  called  a  fully  overlapped  transition  sequence  ( FOTS).  When  overlapping 
is  combined  with  the  MUIO  method  and  applied  to  Figure  3.  a  minimal  length  test  sequence 
of  3 1  steps  is  generated.  The  procedure  for  computing  a  FOTS  is  similar  to  determining 
sequence  with  the  MUIO  method;  details  can  be  found  in  [YANG90]. 

D.  SUMMARY 

The  apparent  goal  of  the  U,  RCP,  MUIO,  and  MUIO  with  overlapping  methods  seems 
to  be  to  shorten  the  length  of  the  test  sequence,  and  most  of  these  techniques  u.se 
complicated,  optimization  techniques  to  produce  an  optimal  length  sequence.  However, 
since  the  purpose  of  conformance  testing  is  to  verify  that  the  behavior  of  a  protocol 
implementation  is  consistent  with  its  specification,  it  seems  that  the  major  emphasis  of  the 
test  procedure  should  be  on  the  correctness  of  the  test  sequence  rather  than  on  its  brevity 
In  other  words,  the  purpose  of  a  test  method  should  be  aligned  with  the  purpose  of 
conformance  testing,  which  is  to  detect  errors  in  faulty  protocol  implementations. 

The  techniques  presented  in  the  previous  section  are  intended  for  use  with  a  protocol 
described  as  an  incompletely  specified  finite  state  machine.  Since  protocols  are  rarely 
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specified  in  this  manner,  the  translation  from  specification  to  I/O  diagram  is  difficult  and 
error-prone.  Protocol  models  which  are  designed  for  specification  puiposes  tend  to  have 
powerful  program  language  constructs,  which  simplify  specification,  but  may  prove 
difficult  to  analyze.  On  the  other  hand,  models  which  are  designed  with  analysis  in  mind, 
such  as  the  CFSM  model  used  by  the  previous  test  methods,  might  be  considered  too  simple 
for  the  specification  of  modem,  complex  protocols  [LUND90(b)].  What  is  needed  is  a  test 
method  that  is  based  on  a  protocol  specification  model  that  eases  the  tasks  of  analysis  and 
verification. 

This  paper  discusses  a  confonnance  test  method  for  generating  a  test  sequence  for  a 
communication  protocol  specified  as  a  system  of  communicating  machines  (SCM).  The 
SCM  specification  method  was  designed  with  protocol  specification  and  verification  in 
mind,  so  it  lends  itself  naturally  to  conformance  testing.  A  number  of  current 
communication  protocols  such  as  GO-B  ACK-N  data  link  protocol.  Token  Bus.  CSMA/CD, 
and  FDDI  have  been  specified  with  SCM.  and  tested  with  the  procedure  presented  here. 
Recently,  a  software  tool  was  created  which  successfully  automates  the  specification 
process  using  SCM  (ROTH  92].  This  automated  tool  helps  the  test  designer  to  analyze  the 
protocol  specification  much  more  easily.  This  does  not  necessarily  guarantee  a  greater 
ability  to  produce  a  better  test  sequence,  but  the  close  relationship  between  the 
specification,  verification,  and  test  methods  gives  some  assurance  that  the  implementation 
is  consistent  with  its  specification. 

E.  SYSTEMS  OF  COMMUNICATING  MACHINES 

In  this  section  the  model  used  to  specify  the  protocol  is  briefly  described.  A  more 
detailed  description  appears  in  [LUND9Ua)]. 

A  system  of  communicating  machines  is  an  ordered  pair  C  =  (M,V),  where 

A/=|m/,/H2 . m„) 

is  a  finite  set  of  machines,  and 

Y={v/,Vj,...vJ 
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is  a  finite  set  of  shared  variables,  with  two  designated  subsets  /?,  and  Vf,  specified  for  each 
machine  rtij.  The  subset  /?,  of  V  is  called  the  set  of  read  access  variables  for  machine  ni,, 
and  the  subset  W,  the  set  of  n  i  tre  access  variables  for  ni,. 

Each  machine  m,-  e  M  is  defined  by  a  tuple  (S,.So.L,.Nj,Xj).  where 

(1 )  5,  is  a  finite  set  of  states; 

(2)  sq  £  Sf  is  a  designated  state  called  the  initial  srare  of  m,. 

(3)  L,  is  a  finite  set  of  local  variables, 

(4)  Nj  is  a  finite  set  of  names,  each  of  which  is  associated  with  a  unique  pair  (p.a). 
where  p  is  a  predicate  on  the  variables  of  Livj  Ri  and  a  is  an  action  on  the  variables  of 
Li  u  /Ri  vj  Wi.  Specifically,  an  action  is  a  partial  function 

a:Lt  X  Ri  — ^  Li  x  Wi 

from  the  values  contained  in  the  local  variables  and  read  access  variables  to  the  values  of 
the  local  variables  and  write  access  variables. 

(5)  Xf.  Si  X  Ni  Si  is  a  transition  function,  which  is  a  partial  function  from  the  states 
and  names  of  m,  to  the  states  of  m,. 

Machines  model  the  entities,  which  in  a  protocol  system  are  processes  and  channels. 
The  shared  variables  are  the  means  of  communication  between  the  machines.  Intuitively. 
Rf  and  arc  the  subsets  of  V  to  which  m,  has  read  and  write  access,  respectively.  A 
machine  is  allowed  to  make  a  transition  from  one  state  to  another  when  the  predicate 
associated  with  the  name  for  that  transition  is  true.  Upon  taking  the  transition,  the  action 
associated  with  that  name  is  executed. 

The  set  L^  of  local  variables  specifies  a  name  and  a  range  for  each.  The  range  must  be 
a  finite  or  countable  set  of  values. 

A  system  state  tuple  is  a  tuple  of  ail  machine  states.  That  is.  if  (M.V)  is  a  system  of  n 
communicating  machines,  and  s,.  for  is  the  state  of  machine  m„  then  the  n-tuple 

{s,,S2,...rS„)  is  the  system  state  tuple  of  (M.V). 
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A  system  state  is  a  system  state  tuple  together  with  its  enabled  outgoing  transitions 
Two  system  states  are  equivalent  if  every  machine  is  in  the  same  state,  ami  the  satne 
outgoing  transitions  are  enabled. 

The  initial  system  state  is  the  system  state  such  that  every  machine  is  in  its  initial  state, 
and  the  enabled  outgoing  transitions  are  the  same  as  in  the  initial  global  state. 

The  global  state  of  a  system  consists  of  the  system  state,  plus  the  values  of  all 
variables,  both  local  and  shared.  The  initial  global  state  is  the  initial  system  state,  with  the 
additional  requirement  that  all  variables  have  their  initial  values.  A  global  state 
corr  esponds  to  a  system  state  if  every  machine  is  in  the  same  state  and  the  same  outgoing 
transitions  are  enabled. 

Let  X(j,,n)  =  be  a  transition  which  is  defined  on  machine  rn,.  Transition  T  is  enabled 
if  the  enabling  predicate  p,  associated  with  name  n,  is  true.  Transition  T  may  be  executed 
whenever  m,  is  in  state  s,  and  the  predicate  p  is  true  (enabled).  The  execution  of  X  is  an 
atomic  action,  in  which  both  the  state  change  and  the  action  a  associated  with  n  occur 
simultaneously. 
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III.  TEST  METHOD 


In  this  section,  the  test  method  is  described.  This  description  is  actually  a  refined 
version  of  the  method  described  in  (LLlND90(b)].  The  input  is  a  protocol  specified  as  a 
system  of  communicating  machines  and  the  output  is  a  complete  test  sequence  and  an  I/O 
diagram.  In  order  to  go  from  the  specification  of  a  protocol  machine  to  a  test  sequence, 
identification  of  the  shared  and  local  variables  is  necessary.  The  shared  and  local  variables 
provide  a  way  for  the  tester  to  provide  input  to  and  observe  output  from  the  machine  during 
testing.  The  test  of  each  edge  or  transition  is  treated  as  a  separate,  individual  test,  and  may 
modify  some  or  all  of  the  shared  and  local  variables. 

The  format  of  each  single  edge  sequence  test  is 

Si  ii.i2.-  in/oi,02....0fn 

where  S]  is  the  state  of  the  machine  at  the  start  of  the  test,  are  the  value.'  of  the  input 

variables  prior  to  the  test,  oj,.. are  the  values  of  the  output  variables  after  the  test,  and 
is  the  state  of  the  machine  at  the  end  of  the  test.  The  input  and  output  variables  are 
determined  before  testing  begins  and  are  taken  from  the  shared  and  local  variables  of  the 
machine.  The  procedure  consists  of  preliminary  steps,  the  test  sequence  generating 
procedure,  and  refining  steps.  A  discussion  of  fault  coverage  follows  the  presentation  of  the 
test  procedure.  While  analysis  of  fault  coverage  is  not  necessary  to  generate  the  test 
sequence,  it  does  help  determine  the  sequence’s  effectiveness. 

A.  PRELIMINARY  STEPS 

1.  2  rom  the  machine  specification  finite  state  diagram,  mark  each  transition  whose 
name  appears  on  more  than  one  arc.  Assign  to  each  such  instance  a  separate  distinguishing 
label. 

2.  From  the  predicate-action  table,  note  the  number  of  clauses  (distinct  conditions)  in 
each  enabling  predicate.  Mark  each  clause. 
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3.  For  each  shared  variable  a,  detemiiiie  if  v  is  an  input  variable,  output  variable,  or 
both.  For  each  x  which  is  both,  split  v  into  two  variables,  vj  and  vq  for  testing  purposes 

4.  For  each  local  variable  /,  determine  if  /  is  used  as  an  interface  to  the  higher  layer  user 
of  this  protocol.  If  so,  mark  /  as  input,  output  or  both.  Each  such  local  variable  is  an  input 
variable  if  it  appears  in  an  enabling  predicate  and  an  output  variable  if  it  appears  in  an  action 
on  the  left  side  of  an  assignment  arrow.  If  /  is  both  input  and  output,  split  it  into  variables 
/[  and  Iq  for  testing  purposes. 

Step  I  ensures  that  each  instance  of  each  transition  is  tested.  A  protocol  specification 
may  have  the  same  transition  name  on  more  than  one  arc;  we  want  to  be  certain  that  every 
arc  is  tested.  Step  2  ensures  that  each  clause  is  tested  individually,  if  possible.  An  enabling 
predicate  may  consist  of  several  clauses,  any  one  of  which  might  be  true,  allowing  the 
transition  to  execute.  In  Steps  3  and  4,  the  shared  and  local  variables  are  identified.  Shared 
variables  provide  the  means  of  communication  between  the  machine  and  other  protocol 
entities,  and  local  variables  allow  communication  with  the  user  of  the  protocol 
Collectively,  these  variables  are  the  means  the  test  designer  has  of  giving  inputs  to  the 
machine  and  observing  its  actions. 

In  some  SCM  specifications,  additional  variables  are  defined  that  are  used  internally 
by  the  protocol  machine  and  are  not  visible  to  the  user  (upper  layer(s)  of  the  protocol  i  or 
the  tester.  Typically,  such  variables  are  counters  or  array  indices.  In  any  case,  however, 
these  variables  should  not  appear  in  the  test  sequence  since  they  are  not  under  tlie  direct 
control  or  observation  of  the  tester. 

B.  TEST  SEQUENCE  GENERATING  PROCEDURE 

1 . 5/<—  initial _state; 

2.  Let  t  -  {p,a)  be  an  untested  transition  from  state.  (This  notation  simply  means  that 
the  current  transition  being  vested,  t.  has  the  predicate,  p,  as  input  and  the  action,  a.  as 
output). 
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(a)  determine  the  values  of  the  input  variables  which  make  exactly  one  of  the 
untested  values  of  p  true.  Check  to  see  if  these  values  allow  any  other  transition  from  this 
state  tci  be  executed.  If  so.  set  additiomiJ  input  vai  tables  to  value, s  thet  eirsure  that  only  the 
transition  being  tested  is  enabled.  Fill  m  the  necessary  input  variables,  and  mark  the  others 
DC  for  "don't  care." 

(b)  determine  and  mark  the  expected  values  for  the  output  variables,  also  record 
the  expected  values  assumed  by  the  local  variables 

(c)  determine  the  expected  next  state  and  set  to  it 

(d)  determine  if  is  transient;  if  not.  label  it  as  a  stop  state"  and  proceed  to  ( ) 

( A  state  is  transient  if  one  or  more  of  its  enabling  predicates  is  tnie  upon  reaching  the  state 
This  means  that  the  machine  can  proceed  to  another  state  without  waiting  for  further  input 
from  the  tester). 

(e)  attempt  to  make  into  a  stop  state  by  setting  DC  values  such  that,  when  state 
5r  is  reached,  none  of  the  enabling  predicates  are  true.  If  successful,  go  to  (3 1 

(f)  $£  is  a  transient  state.  If  more  than  one  transition  leaving  Sp  i.>  enabled, 
arbitrarily  choose  one  and  set  inputs  not  yet  specified,  so  that  only  one  transition  leaving 
5£  is  enabled;  set  t  =  {p,a)  to  this  transition. 

3.  Output  this  test  5j  ii.i2-  *he  next  test  in  the  sequence. 

4.  Mark  the  clause  just  tested.  If  all  clauses  in  transition  t  are  now  tested,  mark  t  as 
tested.  If  all  transitions  arc  now  marked  as  tested,  exit  to  “refining  steps."  Otherwise, 
proceed  to  step  (5). 

5.  Set  S,  to  5£.  If  S,  is  a  stop  state,  proceed  to  (2).  otherwise,  proceed  to  2{b>. 

Step  2(a)  attempts  to  test  each  clause  individually.  This  is  important  so  that  the  tester 
knows  which  transition  was  enabled,  and  therefore  caused  the  transition  to  occur  If  it  is  not 
possible  to  separately  test  each  clause,  then  the  test  designer  must  set  the  input  variables  so 
that  the  clauses  arc  tested  as  thoroughly  as  possible.  Perhaps  they  can  be  tested  in 
conjunction  with  one  another. 


20 


Steps  2(d.e.f)  are  concerned  with  transient  states.  With  the  existence  of  'inch  states,  it 
may  be  impossible  to  veiify  expected  vtilues  of  output  variables,  because  tne  tester  might 
not  be  able  to  determine  which  transition  actually  modified  the  variable.  The  transient  state 
and  possible  multiple  transition  enablings  that  cannot  be  controllet!  in  these  steps,  might 
indicate  the  need  to  modify  the  specification  to  allow  for  bettei  testability. 

Step  5  sets  starting  state  of  the  next  test  in  the  sequence  to  the  ending  state  of  the 
current  test.  In  order  to  exercise  all  parts  of  the  protocol  machine,  some  transitions  may 
have  to  be  executed  more  than  once.  Li  this  instance,  some  judgement  by  the  test  designei 
may  be  needed.  In  the  normal  operation  of  the  machine,  if  certain  transitions  are  executeti 
more  than  others,  the  same  will  likely  be  true  during  testing. 

C.  REFINING  STEPS 

1.  Construct  the  I/O  state  diagram  from  the  test  sequence. 

2.  For  each  state,  determine  a  shortest  UlO  sequence  (if  one  exists).  Append  the  UlO 
sequence  for  $£  to  the  end  of  the  test  sequence.  If  no  UIO  sequence  for  the  current  Sp  exists, 
then  continue  testing  transitions  until  an  Sf  with  a  UIO  sequence  is  visited. 

3.  Check  for  converging  transitions.  (Converging  transitions  are  difficult  to  test  ami 
may  require  special  attention). 

In  Step  1,  the  I/O  diagram  is  constructed  from  the  test  sequence  and  is  a  tool  tc  help 
the  test  designer  ensure  completeness.  This  diagram  is  constructed  directly  from  the  test 
sequence  with  the  knowledge  of  “stop  states.’*  The  directed  arcs  in  the  I/O  diagram  are 
labeled  with  the  corresponding  values  of  the  input  and  output  variables.  Transient  states 
will  not  appear  in  the  I/O  diagram. 

The  purpose  of  the  final  UIO  sequence  in  Step  2  is  to  verify  that  the  last  state  which 
was  reached  in  the  test  sequence  is  indeed  the  currer'  state  of  the  protocol  machine.  Since 
the  details  concerning  the  implementation  of  the  machine  are  assumed  to  be  “hidden"  from 
the  tester,  the  existence  of  at  least  one  state  with  a  UIO  sequence  is  tiecessary.  Without  the 


UIO  sequence,  there  is  no  way  of  knowing  that  the  last  transition  tested  left  the  machine  in 
the  expected  state. 

Converging  transitions,  identified  in  Step  3.  are  distinct  transitions,  with  itlentical 
labels,  which  originate  from  different  states  but  end  in  the  same  state.  They  may  arise 
naturally  in  the  specification  of  a  protocol,  but  should  be  marked  for  careful  observation 
The  existence  of  such  transitions  complicates  the  role  of  the  test  designer  and  makes  error 
detection  difficult.  The  example  protocol  machine  tested  in  a  Chapter  IV  contams 
converging  transitions,  and  the  analysis  of  the  test  sequence  generated  from  this  machine 
will  reveal  their  effects  on  the  quality  of  the  test  sequence 

D.  FAULT  COVERAGE 

For  the  fault  coverage  for  the  protocols  presented  in  this  paper,  four  classes  of  faults 
are  considered  tMIL.L90]. 

•  Type  1;  The  output  of  an  edge  is  altered. 

•  Type  2;  The  input  of  an  edge  Ls  altered  (without  causing  non-determinism). 

•  Type  3:  A  tail  state  of  an  edge  is  altered. 

•  Type  4:  A  head  state  of  an  edge  is  altered  (without  causing  non-determinism ). 

Head  state  and  tail  state  refer  to  the  state  in  which  an  edge  begins  and  ends, 
respectively,  and  a  fault  can  be  defined  as  a  transition  in  the  implementation  under  test 
which  is  not  defined  in  the  specification.  When  testing  for  faults  in  an  implementation  of  a 
protocol,  detecting  faults  of  types  1, 2  and  4  are  generally  trivial.  It  turns  out  that  a  test  for 
the  presence  of  those  categories  of  faults  is  automatically  performed  when  a  test  sequence 
is  checked  for  the  presence  of  a  type  3  fault. 

For  example,  a  type  1  fault  would  be  detected  when  the  test  of  an  sequence  produced 
output  different  from  that  which  was  expected.  A  type  2  fault  would  be  discovered  when, 
for  instance,  no  output  was  generated  in  response  to  an  input  which  should  have  caused  a 
change  in  an  output  variable.  In  this  case,  the  machine  wouldn’t  execute  the  tituisition 
because  the  enabling  predicate(s)  would  not  be  enabled.  A  type  4  error  is  typically  detected 
in  a  similar  matmer.  The  non-detenninism  requirement  for  type  2  and  type  4  errors  is 
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necessary  if,  in  the  lUT,  the  enabling  predicate  of  one  edge  is  altered  such  that  it  is 
equivalent  to  another  enabling  predicate  emanating  from  that  edge.  This  would  result  in  a 
non-dcterminisfic  protocol  machine,  which  is  clearly  untestablc. 

Detection  of  type  3  faults  are  the  most  difficult  to  detect  since  a  single  error  can  go 
undetected  until  the  very  last  edge  sequence  test.  Moreover,  if  the  error  occurs  in  an  edge 
that  exists  more  than  once  in  the  specification,  the  fault  might  not  be  detected.  It  is  wonh 
noting  that,  when  an  error  is  detected  by  a  te.st  sequence,  the  tester  cannot  deduce  what  type 
of  error  exists  in  the  protocol  implementation;  only  the  existence  of  some  type  of  error  is 
known. 
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IV.  APPLICATIONS  OF  TEST  METHOD 


In  this  section  the  test  generating  procedure  is  illustrated  using  two  well-known  local 
area  network  protocols;  Token  Bus  and  FDDI.  The  protocols  are  first  specified  as  a  syswm 
of  communicating  machines  and  then  the  procedure  is  given. 

A.  TOKEN  BUS  PROTOCOL  SPECIFICATION 

The  specification  of  the  Token  Bus  network,  originally  presented  m  fLLrND90(a)|. 
consists  of  the  predicate  action  table  (Table  5),  the  specification  for  each  machine,  given  in 
Figure  4,  and  the  shared  variable  MEDIUM,  also  shown  in  Figure  4.  This  single  shared 
variable  is  used  to  model  the  bus,  which  is  “shared”  by  each  machine.  A  transmission  onto 
the  bus  is  modelled  by  a  write  into  the  shared  variable.  The  fields  of  this  variable 
correspond  to  the  parts  of  the  transmitted  message.  The  first  field,  MEDIUM  t,  takes  the 
values  T,  or  D,  which  indicate  whether  the  frame  is  a  token  or  data  frame;  the  second  field, 
DA.  contains  the  address  of  the  station  to  which  the  message  is  transmitted  (DA  for 
"destination  address”);  the  next  field,  SA,  contains  the  originator’s  address  (SA  for  ‘source 
address”);  finally,  the  data  field  contains  the  data  block  itself. 

The  network  stations,  or  machines,  are  defined  by  a  finite  state  machine,  a  set  of  local 
variables,  and  a  predicate-action  table.  The  initial  state  of  each  machine  is  state  0,  and  the 
shared  variable  is  initially  set  to  contain  the  token  with  the  address  of  one  of  the  stations  in 
the  “DA”  field. 

The  value  of  local  variable  next  is  the  address  of  the  next  downstream  neighbor,  and 
this  is  initialized  so  that  the  entire  network  forms  a  logical  ring.  Local  variable  i  is  used  to 
store  the  station’s  own  address,  and  as  implied  by  their  names,  local  variables  outhltfm^(} 
inhufaie  used  for  storing  data  blocks  to  be  transmitted  to.  or  received  from  other  machines 
on  the  network.  Outbuf  is  an  array,  and  can  store  a  potentially  large  number  of  data  blocks. 
The  local  variable  j  is  used  to  index  into  this  array.  The  variable  cti  serves  to  count  the 
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number  of  blocks  sent;  it  is  an  upper  bound  on  the  number  of  blocks  which  can  be  sent 
during  a  single  token  holding  period. 

The  initial  state  of  each  machine  is  state  0.  local  variables  j  and  cn  are  initially  set  to 
1.  and  inbuf  an6  ourbufaie  set  to  empty.  Tlie  shared  variable  MEDIUM  initially  contains 
the  token,  with  the  address  of  one  station  in  the  DA  field.  Thus  the  initial  system  state  tuple 
is  (0.0. .,0)  and  the  first  transition  taken  will  be  ger-rk.  executed  by  the  station  which  has  its 
local  variable  i  equal  to  MEDIUM. DA. 

Each  machine  has  four  states.  In  the  initud  state.  0.  the  station  is  quiescent,  merely 
waiting  to  either  receive  the  token,  or  a  message  from  another  station.  If  the  token  appeals 
in  the  variable  MEDIUM  with  the  station  s  own  address,  the  transition  to  state  2  is  taken. 
When  taking  the  get-tk  transition,  the  machine  clears  die  communication  medium  luid  sets 
the  message  counter,  ctr,  to  1 .  In  state  2.  the  station  transmits  any  data  blocks  it  has,  moving 
to  state  3,  or  passes  the  token,  returning  to  state  0.  In  state  3,  the  station  will  return  to  state 
2  if  any  additional  blocks  are  to  be  sent,  until  the  maximum  count  k  is  reached.  When  the 
count  is  reached,  or  when  all  the  station’s  messages  have  been  sent,  the  station  returns  to 
state  0. 

The  receiving  station,  as  with  all  stations  not  in  possession  of  the  token,  will  be  in  state 
0.  The  message  will  appear  in  MEDIUM,  with  the  receiving  station’s  address  in  the  DA 
field.  The  rev  tr<uisition  to  state  1  will  then  be  taken,  the  data  block  copied,  and  the 
MEDIUM  cleared  by  the  ready  transition.  By  clearing  the  medium,  the  receiving  station 
enables  the  sending  station  to  return  to  its  initial  state  (0)  or  to  its  sending  state  (2). 

For  this  simplified  specification,  the  channel  is  assumed  to  be  error  free.  This  means 
that  the  clearing  of  the  medium  by  the  receiver  may  be  taken  as  an  acknowledgment  by  the 
sender.  Thus,  there  is  no  need  for  timers,  time-outs  or  error  checking  on  the  channel. 
Although  many  of  the  finer  details  of  the  IEEE  Token  Bus  network  aie  omitted,  this 
specification  contains  the  main  idea  of  the  Token  Bus  protocol,  and  provides  enough  detail 
for  the  generation  of  a  test  sequence. 
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TABLE  5:  PREDICATE  ACTION  TABLE  FOR  THE  NETWORK  NODES 


transition 

predicate 

action 

rev 

MEDIUM.!  t,D  A)  =  (D.i) 

inbiif*—  MEDIUM  iSA.  datai 

ready 

tnie 

MEDIUM  ir-O:) 

get-dc 

MEDIUM.(i,DA>  =  (T.i) 

MEDIUM  0:  cn  *-  1 

pass 

outbuflj]  =  0 

MEDIUM^  {T.nexr.  i.  0) 

Xmit 

outbuflj]  ^  0 

MEDIUM  *—  outbuf[j\ . 

dr  ♦—  ctr  ®  1 ;  outbuf  fy|  *—  t- :  /  *—  /  ®  1 

tnoreD 

MEDIUM  =  0  A(outbufTjl^0 

A  ctr  ^  k) 

-  -  - 

pass-tk 

MEDIUM  =  0  A  (outbuflj)  =  0 

V  ctr  =  k  +  1 1 

MEDIUM  ir-  (T.next.r.0) 

f  DA  SA  data 

MEDIUM 

i _ 

DA  SA  data 


i:  (my  address)  j:  (1,2,..,^) 


err:  (1,2...,A:+1 )  next:  (address 
of  next  station) 

Figure  4  ;  Specification  of  Network  Nodes 
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B.  TEST  SEQUENCE  GENERATION 

First  the  preliminary  steps  are  carried  out;  these  determine  the  exact  format  of  the  tests 
(i.e..  the  input  and  output  variables).  Then  the  tests  are  generated.  Tlie  numbering  below 
corresponds  to  the  steps  in  the  test  procedure,  for  ease  of  reference. 

1.  Preliminaries 

(1 )  All  transition  labels  are  unique,  so  no  action  is  required. 

(2)  The  pass-rk  transition  has  two  distinct  clauses: 
(MEDIUM  =  Q  A  outbuf[j]  =  0)and  (MEDIUM  =  0  a  err  =  A' +  1 )  We  will  mark 
the  former  as  pass-tk'  and  the  latter  as  pass~rk.  (Thus,  the  pass-tk’  transition  represents  the 
case  when  the  machine  has  no  more  data  to  send  during  the  current  token  holding  period 
and  the  pass-tk  transition  represents  the  case  when  the  machine  has  sent  the  maximum 
number  of  messages  during  the  current  token  holding  period). 

(3)  The  shared  variable  MEDIUM  is  both  an  input  and  an  output  variable. 

(4)  The  local  variable  outbiif  is  both  an  input  variable  and  an  output  variable,  and 
inbuf  is  an  output  variable  only. 

Note  that  in  Step  2.  the  more-D  transition  is  not  separated  into  two  different  clauses 
because  all  three  conditions  must  be  true  for  the  transition  to  be  enabled.  Also  note  that  t. 
next,  j,  and  ctr  are  local  variables,  but  since  they  are  not  used  as  an  interface  to  a  higher 
layer  user  of  this  protocol,  they  arc  not  “visible”  to  the  tester  and  are  not  shown  in  the  test 
sequence. 

From  these  preliminary  steps,  we  can  sec  that  the  test  will  take  the  following  form. 

Si  MEDIUMi  outbufi  /  MEDIUMq  outbufQ  inbuf 
Now  we  are  ready  to  begin  generating  the  test  sequence. 

2.  Sequence  Generation 

(1)  We  begin  in  the  initial  state,  0.  In  step  2.  we  may  choose  any  untested 
transition  emanating  from  state  0;  take  the  get-rk  transition. 
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2(a)  According  to  the  predicate-action  table,  to  enable  this  transition  the  t  field  of 
MEDIUM  must  be  set  to  T  and  the  DA  field  to  the  station’s  address,  which  is  assumed  to 
be  /.  The  remaining  fields  may  be  any  values,  and  are  indicated  by  an  ‘  v’  in  Table  6  The 
other  input  variables  are  set  to  “don’t  care"  or  DC. 

2(b)  When  the  transition  occurs.  MEDIUM  is  set  to  empty. 

2(c)  Sf  is  set  to  the  expected  end  state  for  this  test,  which  is  state  2. 

(3)  Noting  that  the  next  state  is  a  stop  state,  this  completes  die  fust  test  in  the 
sequence,  and  the  appropriate  values  are  output  (Table  6). 

(4)  This  clause  and  transition  are  now  marked  “tested.” 

(5)  The  value  of  5,  is  now  set  to  2.  and  another  iteration  starting  at  step  2  is  called 
for. 


TABLE  6:  TEST  SEQUENCE  FOR  THE  TOKEN  BUS  PROTOCOL 


transition 

Si 

MEDIUM, 

outbuf, 
(1  2) 

MEDIUMo 

outbufQ 

a  2) 

inbuf 

Se 

get-tk 

0 

(T,i.x.x) 

DC  DC 

0 

-  - 

■y 

Xmit 

2 

DC 

X  DC 

X 

0  - 

- 

B 

morcD 

3 

0 

DC  Y 

- 

'  - 

- 

B 

Xmit 

2 

DC 

DC  Y 

Y 

-  0 

- 

B 

pass-tk 

3 

0 

X  DC 

(T,next,i.0) 

-  ■ 

- 

0 

rev 

0 

(D4,X.X) 

DC  DC 

- 

-  - 

(.vx.SA, 

data) 

■ 

ready 

1 

DC 

DC  DC 

0 

-  - 

- 

II 

get-tk 

0 

(T.i,x.x) 

DC  DC 

0 

-  - 

- 

B 

pass 

2 

DC 

0  DC 

(T.next,i.0) 

-  - 

- 

0 

get-tk 

0 

(T,i.x,x) 

DC  DC 

0 

-  - 

- 

B 

Xmit 

2 

DC 

X  DC 

X 

0  - 

- 

3 

pass-tk' 

3 

0 

DC  0 

(T,next,i,0) 

-  - 

- 

0 
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The  next  iteration  of  the  procedure  arbitrarily  selects  the  Xmir  transition,  luid  the 
values  selected  are  shown  as  the  second  test  entered  in  Table  6.  The  expected  ending  state 
of  this  second  test  is  3. 

At  the  next  iteration,  the  morcD  transition  is  chosen,  followed  by  the  Xmit  transition 
back  to  state  3.  We  now  exercise  the  pass-tk  transition  using  the 
{.MEDIUM  =  0  A  ctr  —  A:  +  I )  predicate,  which  leads  us  back  to  the  initial  state  of  0 

The  remaining  untested  transitions  are  executed  in  a  similar  manner  resulting  in  a  final 
test  sequence  of  12  tests.  The  values  of  the  input  and  output  variables  for  all  of  these  tests 
are  shown  in  Table  6. 

3.  Fault  Coverage  for  the  Token  Bus  Test  Sequence 

The  procedure  for  detennining  fault  coverage  consists  of  taking  each  outgoing 
transition  from  each  state  in  the  specification  and  modifying  that  transition  so  that  it  has  a 
different  tail  state.  For  example,  in  a  correct  implementation  of  the  Token  Bus  protocol,  the 
get-tk  transition  has  a  tail  state  of  2.  In  an  incorrect  implementation,  the  get-tk  transition 
could  have  a  tail  state  of  0.1.  or  3.  In  this  specification.  Figure  4.  there  are  4  states  and  7 
transitions,  so  there  are  28  possible  tail  states.  Subtracting  the  7  tail  states  in  a  correct  lUT. 
leaves  21  possible  type  3  errors.  These  are  listed  in  Table  7. 

TABLE  7:  POSSIBLE  TYPE  3  ERRORS  FOR  FIGURE  4 


State 

Transition 

PossibIrEnd 

State 

Result 

0 

get-tk 

0 

detected 

0 

get-tk 

1 

detected 

0 

get-tk 

3 

detected 

0 

rev 

0 

detected 

0 

rev 

2 

detected 

0 

rev 

3 

detected 
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As  an  example  of  how  this  test  sequence  can  be  used  to  detect  an  error,  consider 
the  error  that  could  be  associated  with  the  rev  transition.  In  order  for  the  rev  transition  to  be 
executed,  the  machine  must  be  in  stale  0  and  the  predicate  MEDIUM. (t.DA)  =  (D.i)  must 
be  tme.  The  rev  transition  then  places  the  source  address  of  the  sender  and  the  data  into 
local  variable  inbuf{inbuf  ^  MEDIUM. (SA.data)).  If  this  transition  were  to  end  in  state  0, 
then  either  the  rev  transition  must  be  executed  again,  or  the  get-t/c  transition  is  executed.  If 
the  rev  transition  is  executed  repeatedly,  the  machine  will  be  in  deadlock,  and  the  error 
detected.  If,  on  the  other  hand,  the  gef-tk  transition  is  executed,  MEDIUM  will  be  modified 
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(MEDIUM  ir-  0)  mistakenly,  and  the  error  will  be  delected.  This  type  of  procedure  is 
applied  to  every  possible,  single  type  3  error  to  detennine  if  it  can  be  detecteri. 

A  check  of  the  21  possible  eirors  against  the  test  sequence  (Table  7)  shows  that 
all  faults  will  be  detected  with  the  following  2  exceptions;  ( 1 )  when  the  pass  transitioti  ends 
in  state  3  (instead  of  state  0)  and  (2)  when  the  pass-fk  transition  ends  in  state  2  (instead  of 
state  0).  Closer  inspection  reveals  that  these  particular  errors  are  not  detected  because  they 
Involve  converging  transitions. 

Note  from  Table  4  that  the  enabling  predicates  and  the  corresponding  actions  for 
the  pass-rk  and  pass  transitions  are  almost  identical.  Furthermore,  both  transitions  emimate 
from  different  states  but  end  in  the  same  state,  state  0.  If.  in  a  faulty  implementation, 
transition  pass-tk  ended  at  state  2.  the  error  would  go  undetected  because  the  machine 
would  instantaneously  move  from  stare  2  to  state  0;  this  is  the  correct  state  in  an 
implementation  where  the  error  in  the  pass-rk  transition  does  not  occur.  The  pass  transition 
is  executed  because  the  enabling  predicate  for  the  pass  transition  must  be  “true"  in  order 
for  the  pass-tk  transition  to  have  executed  earlier.  In  general,  errors  involving  converging 
transitions  are  difficult  to  detect  and  are  given  further  treatment  in  chapter  V. 

C.  FDDI  PROTOCOL  SPECIFICATION 

The  Fiber  Distributed  Data  Interface  (FDDI)  is  a  high  speed,  token  ring,  local  area 
network  recently  developed  by  the  American  National  Standard  Institute  (ANSI).  Because 
of  its  reliability  and  high  speed.  FDDI  is  a  very  complex  protocol.  This  is  evidenced  by  its 
sptecification.  The  ANSI  specification  of  this  protocol  contains  two  distinct  machines,  each 
with  six  states,  and  a  total  of  approximately  60  transitions.  Furthermore  this  work  contains 
some  undesirable  ambiguities  that  could  complicate  testing.  Recent  work  rHJND9l(b)| 
involving  FDDI  has  produced  an  SCM  specification  of  an  improved  FDDI  protocol  which 
allows  for  proofs  of  protocol  correctness  and  for  the  development  of  test  procedures.  This 
improved  specification,  though  it  is  more  precise  than  the  ANSI  specification,  is  also  more 
complex;  it  includes  two  machines  with  a  total  of  more  than  100  states  and  250  transitions. 
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In  order  to  effectively  test  such  a  specification,  it  is  necessary  to  break  each  machine 
into  distinct,  separately  testable  entities,  and  perfonn  localized  testing;  that  is  the  approach 
taken  here.  The  specification  provided  here  is  a  portion  of  the  MAC  receiver  state  diagram 
illustrated  in  [LUND9l(b)].  Since  this  work  involved  an  improved  FDD!  specification, 
some  refinements  to  the  example  machine  were  necessary  to  make  it  more  closely  aligned 
with  the  ANSI  specification.  The  purpose  of  the  machine  used  in  this  example  is. 
essentially,  to  analyze  the  stream  of  symbols  being  received  by  the  MAC  layer  and 
determine  whether  or  not  they  represent  the  token. 

This  specification  consists  of  the  predicate  action  table  (Table  8)  and  the  state  diagram 
of  the  receive  token  machine  (Figure  6).  A  complete  description  of  the  notation  userl  in  this 
example  is  beyond  the  scope  of  this  thesis,  however  interested  readers  can  consult 
[LUND91(b)].  The  brief  description  that  follows  should  be  sufficient  to  allow  for  an 
understanding  of  the  operation  of  the  example  machine.  For  the  predicates  in  Table  8.  each 
symbol  represents  a  field  of  an  FDDI  frame;  this  frame  format  is  shown  in  Figure  5 


PA 

SD 

FC 

DA 

SA 

INFO 

FCS 

ED 

FS 

Figure  5  :  Frame  Format 

Each  field  of  the  frame  has  the  following  meaning: 

•  Preamble  (PA)  -  consists  of  16  or  more  idle  symbols  (Ii  .Inja.\l  *hat  signal  a 
start  transition  for  synchronization  of  station  's  clock 

•  Starting  Delimiter  (SD)  -  consists  of  two  symbols  (J  and  K)  that  signal  the 
start  of  receiving  a  frame 

•  Frame  Control  (FC)  -  consists  of  two  data  symbols.  For  our  purposes.  FC 
will  either  contain  (n,n)  uidicating  a  bit  pattern  other  than  the  token,  or  FC 
will  be  equal  to  Token,  which  indicates  that  the  frame  contains  a  the  token. 


•  Destination  Address  ( DA )  -  consists  of  a  number  of  svmhols  that  indicate  the 
destination  address  of  the  frame 


•  Source  Address  (SA)  -  consists  of  a  number  of  symbols  that  indicate  the 
source  address  of  the  frame. 

•  Information  (INFO)  -  consists  of  zero  or  more  symbols  that  represent  the 
message  carried  by  the  frame. 

•  Frame  Check  Sequence  (FCS )  -  consists  of  a  number  of  symbols  that  serve  to 
detect  errors  within  the  frame. 

•  Ending  Delimiter  (ED)  -  consists  of  one  terminate  symbol  (T)  that  indicates  a 
frame  ending.  The  field  is  necessary  to  provide  a  criteria  for  acceptance  of  a 
valid  frame.  The  ED  must  be  met  before  a  frame  is  accepted. 

•  Frame  Status  (FS)  -  consists  of  control  indicator  symbols  that  follow  the 
ending  delimiter  of  a  frame. 

'Tie  example  machine  has  four  states.  In  the  initial  state.  0.  the  machine  is  quiescent, 
merely  waiting  to  either  process  a  symbol  stream  or  to  reset.  If  MACJleset  is  true,  a  reset 
occurs  and  the  machine  remains  in  its  initial  state.  If  the  preamble  {PA^  is  equal  to  f,.  then 
the  first  idle  symbol  has  been  detected  in  the  symbol  stream,  and  the  machine  moves  to 
state  1.  From  state  I,  a  reset  or  invalid  signal  from  the  physical  layer  would  cause  tJie 
machine  to  return  to  its  initial  state;  however,  if  PA,  is  equal  to  the  maximum  number  of 
idle  symbols  and  the  first  symbol  of  the  starting  delimiter  (7)  has  been  received,  the 
machine  moves  to  state  2.  The  machine  would  then  move  to  state  3  if  the  rest  of  the  starting 
delimiter  was  received  correctly  and  the  frame  control  symbol  was  set  to  the  token.  From 
state  3,  the  strip  on^tk  transition  would  be  taken  if  a  preamble  is  detected  with  only  one 
idle  symbol,  and  the  frame  control  indicates  a  value  other  than  the  token.  The 
format  error  on _tk  would  be  exercised  if,  in  addition  to  the  above  conditions,  the  ending 
delimiter  was  not  equal  to  the  tenninate  symbol  or  the  preamble  did  not  contain  lui  itile 
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symbol.  Finally,  the  token jcvd  transition  is  taken  if  the  terminate  symbol  is  received 
correctly. 

It  is  important  to  emphasize  that  tiiis  specification  comprises  a  very  small  ponion  of 
the  entire  FDDI  specification,  and  the  only  way  to  test  such  a  complc.x  specification  is  to 
break  it  down  into  more  manageable  parts.  TTie  example  given  here  is  representative  of  the 
complexity  that  would  be  associated  with  other  machines  in  the  FDDI  specification 


TABLE  8:  PREDICATE  ACTION  TABLE  FOR  RECEIVE  TOKEN  MACHINE 


transition 

predicate 

action 

Reset 

MAC_Reset  =  tnie 

T_Neg  ^  T_Max; 

S!gnai_Start 

PH_Indication(  symbol)  =  PAxfl,  1  a 
(symbol  =  PA^[I|]) 

TVX  <—  reset;  TV'X  en.sbledl;  SIGNAL 
idle: 

Invalid 

PH_Invalid  =  true 

SIGNAL  FO.Error; 

Start 

PH  Indication(svmbol)  =  PA,fI|  .Im„) 
SD,[J] 

Idle  4-  off;  SIGNAL  RC_Sian; 

Token 

PH_Indication(  symbol)  =  1  PA^n  1 

SD,(JK1I  AFC,  =  Token 

SIGNAL  PDU.Dc; 

Strip_on_Tk 

PH_lDdicatioo(  symbol)  =  f  PArfli.mM). 
SD,(JK].FC,(n.nl.PA,(l,]l 

SIGNAL  idle: 

FoiTnat_Error 

_on_Tk 

PH_Indication(symbol)  =  PA,[I; 

SD4JK],  FC^an),  (^  PA,[I,J  v 
-EDXr.T] ) 

SIGNAL  FO_Error; 

Token_Rcvd 

PH_Indication(symbol)  =  PA^{I/..I^„j, 
SDJJK],  FC,lD.n].  ED,(T.T] 

SIGNAL  Tk_Rcvd; 
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Figure  6  ;  FDDl  Receive  Token  Specification 

D.  TEST  SEQUENCE  GENERATION 

These  steps  are  similar  to  those  provided  for  the  Token  Bus  test  sequence.  Again,  the 
numbering  below  corresponds  to  the  steps  in  the  test  procedure. 

1.  Preliminaries 

(1)  There  are  four  reset  transitions  and  three  invalid  transitions,  and  these  are 
labeled  with  subscripts  corresponding  to  the  number  of  the  state  from  which  they  originate. 

(2)  Each  enabling  predicate  has  one  clause. 

(3)  The  shared  variables  T_Neg  and  IVX  are  output  variables. 

(4)  The  local  variables  PH  Indication.  FH  Invalid,  and  MAC  Reset  are  input 
variables  and  local  variables  Idle.  RCJSrart,  PDUJTk.  FO_Error.  TK  Rcrd.  and  Flails  are 
output  variables. 

From  these  preliminary  steps,  we  can  see  that  the  test  will  take  the  following  fonn: 
S,  PH  Jndiation  PH  Invalid  MAC _Reset  I  T  Neg  nCddle  RCJrari  PDUJk  FO  En  m  TK  RvmI  Sp, 
Now  we  are  ready  to  begin  generating  the  test  sequence. 
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2.  Sequence  Generation 


(1)  We  begin  at  the  initiiU  state.  0.  In  step  2.  we  may  choose  any  untesteil 
transition  emanating  from  state  0;  t;ike  the  n’scfo  transition. 

2(a)  According  to  the  predicate  action  table,  to  enable  this  transition,  MAC  Reset 
must  be  set  to  “true."  The  remaining  input  variables  are  set  to  DC 

2(b)  When  the  transition  occurs.  T_Ne,<^  is  set  to  T  Ma.x. 

2(c)  Sg  is  set  to  the  expected  end  state  for  this  test,  which  is  state  0. 

(3)  Noting  that  the  next  state  is  a  stop  state,  this  completes  the  fust  test  in  the 
sequence.  The  appropriate  values  are  now  output  (Table  9) 

(4)  This  transition  is  now  marked  “tested." 

(5)  The  value  of  Sj  is  now  set  to  0.  and  another  iteration  starting  at  step  2  is  called 
for. 


TABLE  9:  FDDI  RECEIVE  TOKEN  TEST  SEQUENCE 


(ransitton 

PH_Imlkatt<Mi 

ISJfllboll 

PH.InraM 

MAC_ 

Reset 

T_Ne* 

TVX 

Idle 

Rc_ 

.Stan 

PDU  T 
h” 

Ff)_ 

Error 

0.1 

Ftaw 

B 

0 

. 

DC 

ente 

- 

n 

Signal_S(irt 

0 

PAJl/l  A  symbol 
-PAJIJ 

DC 

DC 

■ 

reset 

enable 

on 

■ 

■ 

■ 

■ 

1 

Invalid; 

1 

DC 

inie 

DC 

- 

- 

- 

on 

ft 

Sign*l_SUrt 

0 

PA^I/Ja  symbol 

=  PA4I/1 

DC 

DC 

■ 

reset 

enable 

on 

' 

• 

' 

1 

React; 

I 

DC 

DC 

irve 

12213 

- 

- 

- 

- 

- 

n 

Signal_SUit 

0 

PA41;)  A  symbol 

-PA4I,J 

DC 

DC 

■ 

reset 

enable 

on 

■ 

■ 

■ 

■ 

B 

Sunt 

1 

PA4l,.i«.l, 

SD4J1 

DC 

DC 

■ 

■ 

off 

on 

■ 

■ 

clear 

B 

Reset] 

2 

DC 

DC 

ITVC 

|T_Ma* 

D 

Stgi»l_Start 

0 

PA4I/)a  symbol 

-PA4U 

DC 

DC 

■ 

reset 

enable 

on 

• 

s 

■ 

■ 

■ 

B 

Sian 

1 

pa,(1/..i.»„). 

SD4I] 

DC 

DC 

■ 

■ 

off 

on 

■ 

■ 

■ 

t  |ej»r 

B 

Invalid;} 

a 

DC 

true 

DC 

■ 

Bl 

n 

SignaLSlarl 

0 

PA4IJ  A  symbol 

-  PA4I/1 

DC 

DC 

m 

reset 

enable 

on 

■ 

■ 

■ 

■ 

B 

Stan 

1 

PA4I,«««1. 

SD4J) 

DC 

DC 

■ 

■ 

off 

on 

:  ! 

■ 

■ 

clear  1 

B 
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.  _  o  PH  „„  ,  M.\C  ^  Rc  POt  T  FO  TK 

S,  PHJnv.lld  T^X  k'  E„;,  Rcvd 


Token  j 

1  PA4I,.I,.„I 
SD,(JK]  A  FC, 
“Token 

DC 

DC 

Sirip_or>_TJc 

SD.inCl.FC,(n,n), 

PA,(I,| 

DC 

DC 

Sfart 

1 

PA.fl,  t_|. 
SD.lJl 

nr 

DC 

Token 

1 

PA,(I;. 

SD,(JK1  A  FC, 
=Tokcn 

DC 

DC 

Fofmac_EiTor 

_on_Tk 

t 

PA,fI;..I_). 
SD,(JKl.FC4n.n|. 
(-.PAJl,)  V 
-)  ED,lT.Ti ) 

DC 

DC 

Slart 

1 

PA,!1,.I,„], 

SD,(}1 

DC 

DC 

Token 

-» 

1  PA,[I,..I„„] 

SD,(tKl  A  FC, 
*Token 

DC 

DC 

Tokcn_Rcvd 

3 

PA,(I,..I^). 

SD,(nC|,FC,ln.nl. 

ED,(TT1 

DC 

DC 

Sun 

1 

PA,[1;..I^), 

SD,(J) 

DC 

DC 

Token 

2 

PA4t,.i.,„] 

SD4JK1  A  FC, 
“Token 

DC 

DC 

Invalid} 

a 

DC 

trtfe 

DC 

i  Sign«l_S«*n 

0 

PA,(I,1  A  symbol 
=  PA4l',l 

DC 

DC 

Sun 

' 

PA,(I,. 

SD,(J) 

DC 

DC 

Token 

~2~ 

PA4I,..l„) 
SD,(rK)AFC,  i 
■Token 

DC 

DC 

Reset) 

DC 

DC 

true 

Signal_Sun 

'  0 

PA,{I(J  A  symbol 

DC 

reset 

on 

enable 

The  next  iteration  of  the  procedure  arbitrarily  selects  the  si'^nal  start  transition, 
and  the  values  selected  are  shown  as  the  second  test  entered  in  Table  9.  The  expecteil 
ending  state  of  this  second  test  is  1.  At  the  next  iteration,  the  invalid,  transition  is  cliosen. 
followed  by  the  signal  start  transition  back  to  state  1 . 
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The  remaining  untested  transitions  are  executed  in  a  similar  manner  resulting  in  a 
final  test  sequence  of  29  steps.  Tlie  values  of  the  input  and  output  variables  fur  all  of  these 
tests  are  shown  in  Table  9. 

3.  Fault  Coverage  for  the  FDDI  Test  Sequence 

ThedeterminationoffaultcoverageforthistestsequenceisidenticaltotheTokenBustest 
sequence.  In  this  specification.  Figure  6.  there  are  4  states  and  13  transitions,  so  there  are 
52  possible  tail  states.  Subtracting  the  13  fail  states  in  a  correct  ILT.  leaves  39  possible  type 
3  errors.  These  errors  along  with  the  results  of  each  test  are  listed  in  Table  10 


TABLE  10:  POSSIBLE  TYPE  3  ERRORS  FOR  FIGURE  5 


State 

Transition 

Possible 

End 

State 

Result 

0 

reset„ 

1 

undetected 

0 

resetg 

2 

undetected 

0 

reset„ 

3 

undetected 

0 

signal  _start 

0 

detected 

0 

signal_starr 

2 

detected 

0 

signaljstart 

3 

detected 

1 

reset, 

1 

detected 

1 

reset, 

2 

undetected 

1 

reset, 

3 

undetected 

1 

invalid  / 

1 

detected 

1 

invalid  1 

2 

undetected 

1 

invalid  1 

3 

undetected 

1 

start 

0 

detected 

1 

start 

1 

detected 
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State 


Transition 


Possible 

End 

Slate 


Result 


39 


A  check  of  the  39  possible  type  3  errors  against  the  test  sequence  (Table  9)  shows 
that  there  are  15  faults  which  are  not  defected.  Note  that  in  each  such  instance,  the  error  is 
not  detected  because  it  occurs  in  tlie  presence  of  one  or  more  converging  trjuisitions;  tun 
single,  type  3  error  that  does  not  involve  a  converging  transition  will  be  detected. 

For  instance,  consider  the  error  that  could  be  as.sociated  with  the  uorr 

transition.  In  order  for  this  transition  to  be  executed,  the  machine  must  be  in  staw  0  and  the 
predicate  PH Jndicationi symbol)  =  PAiitj}  a  i symbol  =  PA,.[li]}  must  be  true  This 
transition  then  resets  and  enables  the  valid  transmission  timer  (TVX)  and  enables  the  uUe 
signal.  If  this  transition  were  to  end  in  state  0.  then  either  the  signal  start  transition  must 
be  executed  again,  or  the  reset,,  transition  is  executed.  If  the  signal  start  transition  is 
executed  repeatedly,  the  machine  will  appear  to  be  in  deadlock,  and  the  error  will  be 
detected.  The  same  result,  deadlock,  will  also  occur  if  res€t„  is  repeatedly  executed.  Again, 
as  in  the  previous  example,  this  type  of  procedure  is  applied  to  every  potential  single,  type 
3  error  to  determine  if  it  can  be  detected. 

E.  IMPROVING  TESTABILITY 

1.  Token  Bus  Specification 

The  fault  coverage  for  the  test  sequence  presented  for  the  Token  Bus  protocol 
reveals  two  ways  in  which  the  protocol  specification’s  testability  is  compromised. 

First,  from  Figure  4,  note  that  state  J  is  a  transient  state.  Since  the  only  transition 
emanating  from  this  state  is  ready,  and  the  enabling  predicate  for  ready  is  "true.”  the 
machine  moves  from  state  I  back  to  state  0  without  any  input  from  the  tester  The  problem 
is  easily  resolved,  however,  by  adding  the  action  for  the  ready  transition  to  the  action  for 
the  rev  transition,  and  then  removing  the  ready  arc  from  the  predicate  action  table  and  the 
sta,e  diagram;  this  eliminates  the  need  loi  state  I  in  the  state  diagram.  It  is  likely  that  the 
designer  of  the  specification  merely  included  state  /  in  the  original  specification,  in  order 
to  facilitate  its  understanding.  Fortunately,  the  presence  of  the  transient  state  in  the  original 


example  does  not  have  an  adverse  effect  on  the  fault  coverage  provided  hy  the  test 
sequence.  However,  this  is  not  always  the  case 

The  second  problem  the  test  sequence  reveals  is  the  existence  of  the  converging 
transitions  mentioned  earlier.  This  situation  is  more  difficult  to  resolve  The  purpose  of 
these  two  transitions  is  to  bring  the  machine  back  to  its  initial  state  once  it  (a)  possesses  the 
token  but  has  no  data  to  send  (pass),  or  (b)  has  already  sent  the  maximum  numi^er  of 
messages  allowed  during  a  single  token  holding  period  ipass-rk).  Since  the  goal  of  the 
transitions  is  essentially  the  same  ti  e.  to  pa.ss  the  token  to  the  next  machine)  it  is  difficult 
for  the  test  sequence  to  distinguish  between  thetn.  In  this  case,  the  tester  should  mark  the 
transitions  as  a  potential  problem  and  continue  testing. 

2.  IFVDI  Specification 

The  major  problem  that  analysis  of  the  test  sequence  reveals  about  this 
specification  is  the  existence  of  converging  transitions. 

In  Figure  6  there  are  thirteen  transitions,  seven  of  which  aic  converging 
transitions.  There  are  four  converging  reset  transitions  whose  purpose  i.s  to  return  the 
machine  to  its  initial  state  upon  the  “resetting  ”  of  the  MAC  layer.  The  three  imaliii 
transitions  ending  in  state  0,  which  indicate  to  the  MAC  layer  that  the  phy.sical  layer  has 
encountered  an  invalid  frame,  are  also  converging  transitions.  Although  these  errors  go 
undetected  by  the  test  sequence,  the  occurrence  of  any  one  of  them  in  an  implementation 
that  is  otherwise  error  free,  would  not  zdfect  the  normal  operation  of  the  protocol.  Tliis  is 
because  all  of  the  reset  transitions  and  all  of  the  invalid  transitions  have  exactly  the  same 
function,  respectively. 

While  it  is  comforting  to  note  that,  in  this  case,  the  presence  of  these  eirors  does 
not  adversely  affect  the  test  sequence,  this  will  not  always  be  so.  Unfortunately,  tliere  is 
little  that  the  tester  or  protocol  designer  can  change  In  this  instance  without  altering  the 
operating  characteristics  of  the  machine. 
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V.  PROOF  OF  FAULT  COVERAGE 


This  chapter  is  concerned  with  determining  the  fault  coverage  produced  by  the  test 
method  we  have  been  discussing.  Essentially,  the  testing  problem  is  a  matter  of  detennming 
the  equivalence  of  two  machines;  the  specification  machine  and  tlie  machine 
implementation.  If  the  two  machines  are  equivalent,  then  the  machine  implementation, 
seen  as  a  black  box.  should  generate  the  same  output  as  the  specification  machine  when 
both  are  presented  with  the  same  input.  Again,  since  very  little  can  be  assumed  about  the 
internal  strucmre  of  the  implementation  machine,  the  only  way  to  determine  equivalence  is 
to  probe  both  machines  with  input  sequences  and  compare  the  resulting  output  sequences. 
The  problem  now  is  to  figure  out  the  right  set  of  inputs  and  outputs  (test  sequences)  to 
determine  whether  or  not  the  machines  are  equivalent. 

In  many  ways  this  problem  is  related  to  the  state  verification  problem,  which  has  been 
shown  to  be  unsolvable.  However,  by  limiting  the  number  and  type  of  errors  that  can  occur 
in  an  implementation,  it  is  possible  to  devise  a  procedure  that  generates  a  test  sequence 
which  is  guaranteed  to  detect  certain  types  of  serious  errors.  The  occurrence  of  an  error  in 
a  machine  that  contains  converging  transitions  presents  special  problems  for  the  test 
designer,  so  care  is  taken  in  specifying  exactly  what  constitutes  a  converging  transition. 

Two  transitions  and  t2=^{p2,02^  art  converging  rransihonx  \f  M  of  the 

following  conditions  hold: 

(1)  transitions  tj  and  have  different  head  states  but  the  same  tail  state; 

(2)  (pi=P2)ot{pi  =^P2); 

(3)  (a;  =  02)  or  their  actions  on  all  output  variables  are  identical. 
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In  the  absence  of  converging  triutsitions.  it  is  possible  to  devise  a  metho<.l  that  will 
provide  good  fault  coverage,  as  is  evidenced  by  the  following  proof  This  proof  is  by 
contradiction. 

Let  X'  be  a  protocol  implementation  under  test  (IIJT)  of  a  protocol  machine  X, 
specified  by  SCM. 

Theorem:  If  (1 ),  X  has  no  converging  transitions,  and  (2),  the  last  transition  in  the  test 
of  X  is  a  UlO  sequence,  then  the  test  sequence  will  detect  any  single  type  3  error 

Proof:  Suppose  not.  Then  there  is  such  a  machine  which  can  be  implemented  with  a 
single  type  3  error,  which  the  test  sequence  will  not  detect. 

Let  H  be  the  state  of  the  lUT  at  which  the  error  occurs;  that  is.  from  which  the 
transition,  say  ‘P’.  goes  to  the  wrong  state  (Figure  7). 

correct 
state 


actual 
state 

Figure  7  ;  Type  3  error 

Now  from  the  initial  state  to  H,  the  test  sequence  has  progressed  correctly. 
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Fe 

Let  (H,  Ej,  E2,...,  F,...Fe)  be  the  sequence  of  states  as  expected  to  be  visited  by  the 
test  sequence  and  shown  in  Table  11. 


Figure  8  ;  States  Visited  in  Protocol  Machine 


Similarly,  let  E’l,...,  F’g  be  the  actual  sequence  taken  by  the  faulty  IIJT  (Figure  8). 
Since  no  error  is  detected,  the  sequence  Q’],  Q’2 is  exactly  equivalent  to  Qj.  Q2  • 
However,  F,...  Fg  is  a  UIO  sequence;  hence.  F’,...  F’g  must  be  exactly  the  same  sequence 
of  states  and  transitions,  or  else  condition  1  is  violated.  Otherwise,  F,...  F'g  must  be  F....  Fg. 
Then  there  must  have  been  a  converging  transition  in  the  sequence  Q‘|.  QS-  .  which 
violates  condition  II.  QED. 
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VI.  CONCLUSION 


A.  CONTRIBUTIONS  OF  THIS  RESEARCH 

The  goal  of  this  thesis  was  to  present  a  procedure  which  generates  a  test  sequence  for 
a  communication  protocol,  that  takes  a.s  input  a  protocol  specified  as  a  sxsTvm  of 
communicating  machines,  and  gives  as  output,  a  complete  test  sequence  Tliree  recent 
conformance  test  procedures  were  reviewed  and  their  suitability  for  testing  current 
communication  protocols  was  discussed.  A  brief  specification  of  two  well  known  local  aiea 
network  protocols  was  given  using  SCM  and  test  sequences  were  generated  and  analyzeii 
to  determine  the  fault  coverage  they  afforded.  Finally,  a  proof  was  given  that  shows  the 
error  detection  capability  of  this  test  method. 

The  test  method  introduced  here  further  demonstrates  the  flexibility  of  the  SCM 
model.  A  protocol  can  be  specified,  verified  and  tested  using  techniques  based  on  this 
model.  In  the  test  procedure,  every  instance  of  every  transition  in  the  machine  specification 
is  tested  along  with  each  clause  in  the  enabling  predicates.  The  preliminary  steps  detennine 
the  input  and  output  variables,  the  sequence  generating  procedure  produces  the  test 
sequence,  and  the  refining  steps  assist  in  determining  fault  coverage.  It  was  shown  that  this 
method  provides  good  fault  coverage  in  the  absence  of  converging  transitions. 

The  example  test  sequences  for  Token  Bus  and  FDDI  demonstrate  the  application  of 
the  specification  and  testing  methods  associated  with  the  systems  of  communicating 
machines  model.  Since  these  protocols  are  in  wide  use  today  in  many  networks,  their 
presence  as  examples  illustrates  further  the  usefulness  of  this  test  method.  Indeed,  a  test 
designer  would  have  a  difficult  time  trying  to  generate  a  test  sequence  for  these  protocols 
using  any  of  the  test  methods  discussed  in  Chapter  11.  Again,  using  a  protocol  specification 
method  that  has  testing  in  mind  yields  much  better  results  than  using  a  specification  method 
that  was  designed  without  regard  to  confonnance  testing. 
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The  proof  of  fault  coverage  presented  here  is  important  to  the  test  designer  because  it 
provides  assurance  that,  under  certain  cucumstances.  a  serious  error  in  a  piotocol 
unplementation  will  be  detected.  While  some  of  the  current  literature  discusses  the 
correctness  of  a  test  sequence,  the  main  emphasis  seems  to  lie  in  shortening  the  sequence 
length.  Our  procedure,  however,  emphasizes  the  ability  of  the  sequence  to  detect  errors 
rather  than  achieve  an  optimal  test  sequence  length.  After  all,  if  the  protocol  test  method  is 
automated,  the  length  of  the  test  sequence  is  of  little  importance;  the  fault  coverage 
provided  by  the  sequence  is  the  important  part.  It  is  again  necessary  to  emphasize  tliat  test 
methods  can  only  test  for  the  presence  of  desirable  behavior  in  a  protocol  machine.  It  is  not 
possible  to  exhaustively  test  for  the  presence  of  undesirable  behavior  since  one  cannot 
foresee  all  possible  errors  that  could  occur  in  an  implementation. 

B.  AREAS  FOR  FURTHER  RESEARCH 

Further  research  might  concentrate  on  extending  the  error  detection  capabil  ities  of  this 
method  to  detect  multiple  errors  or  perhaps  to  detect  them  m  the  presence  of  converging 
transitions.  Since  this  method  treats  a  protocol  implementation  as  a  “black  box  ’  the  test 
designer  knows  nothing  about  the  internal  workings  of  the  machine;  the  tester  can  only 
monitor  the  output  of  the  machine  in  response  to  certain  inputs.  For  this  reason.  LHO 
sequences  are  needed  to  verify  the  state  of  the  machine  at  a  given  instant.  It  would  be 
interesting  to  see  how  different  “distinguishing  sequences”  could  be  used  to  better  perfonn 
this  function  in  the  presence  of  errors. 

The  recent  automation  of  the  specification  and  analysis  portion  of  the  SCM  model 
[ROTH  92],  opens  the  door  for  the  possible  automation  of  the  test  method  introduced  here. 
The  procedure  is  fairly  straightforward  requiring  the  intervention  of  the  test  designer  on 
matters  such  as  transient  states  and  transitions  with  multiple  clauses,  but  by  startmg  with 
simple  protocols  that  do  not  contain  any  of  these  complicating  factors  it  is  reasonable  to 
assume  that  the  procedure  can  be  automated. 
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By  showing  the  types  of  faults  that  coinmoitly  go  undetected  by  test  sequences,  this 
re.search  also  provides  some  insight  into  de.sjgjiuig  protocol  sprcnic'’s  iJiai  are  belter 
suited  for  testing. 
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